Skip to content

Clear gRPC Monitor request only after monitor successfully closes #1771

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 17, 2022

Conversation

cmaglie
Copy link
Member

@cmaglie cmaglie commented Jun 16, 2022

Please check if the PR fulfills these requirements

  • The PR has no duplicates (please search among the Pull Requests
    before creating one)
  • The PR follows
    our contributing guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)
  • UPGRADING.md has been updated with a migration guide (for breaking changes)

What kind of change does this PR introduce?
This is a countermeasure for kernel/firwmare bugs: resources may take a few milliseconds to actually get freed for real after killing the process, or even after a regular closing.
This delay makes the caller more resilient to this kind of issues.
The gRPC Monitor request is closed only after the monitor is successfully closed.

What is the current behavior?
gRPC callers of Monitor will get the streaming request close as soon as the CLI asks the monitor to "close" (but without waiting for the monitor to actually close).

What is the new behavior?
Now the streaming request is closed after the monitor process executes the "close" operation

Does this PR introduce a breaking change, and is titled accordingly?
No

@per1234 per1234 added topic: code Related to content of the project itself topic: gRPC Related to the gRPC interface labels Jun 17, 2022
@cmaglie cmaglie self-assigned this Jun 17, 2022
@cmaglie
Copy link
Member Author

cmaglie commented Jun 17, 2022

Actually, it seems that the problem is not the delay, but the incorrect synchronization on the gRPC server, I'm updating the PR to reflect that.

@cmaglie cmaglie force-pushed the small_delay_monitor_close branch from 3f2691b to 6625dac Compare June 17, 2022 09:33
@cmaglie cmaglie changed the title gRPC: Added a small delay after monitor closing Clear gRPC Monitor request only after monitor successfully closes Jun 17, 2022
@cmaglie cmaglie requested a review from a team June 17, 2022 09:40
@cmaglie cmaglie added the criticality: highest Of highest impact label Jun 17, 2022
@cmaglie cmaglie added this to the arduino-cli 0.24.0 milestone Jun 17, 2022
Copy link
Contributor

@per1234 per1234 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change fixes the problem I reported at arduino/arduino-ide#1040 (review), where Serial Monitor still had control over the board's port when the "1200 bps touch" connection was attempted by the the upload process, causing that connection to fail with a "Serial port busy" error, and thus also causing the upload to fail due to the board never being put in bootloader mode.

Thanks Cristian!

@per1234 per1234 added the type: imperfection Perceived defect in any part of project label Jun 17, 2022
@cmaglie cmaglie merged commit 2ee2138 into arduino:master Jun 17, 2022
@cmaglie cmaglie deleted the small_delay_monitor_close branch June 17, 2022 10:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
criticality: highest Of highest impact topic: code Related to content of the project itself topic: gRPC Related to the gRPC interface type: imperfection Perceived defect in any part of project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants